\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 ring
\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0 to any objects
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 from
\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0 the nib file that you want other objects to be able to talk to.
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 (You must have created outlets in Interface Builder for these objects, in order for the objects to be assigned to instance variables.)
\pard\tx1140\tx2300\tx3440\tx4600\tx5760\tx6900\tx8060\tx9200\tx10360\tx11520\fc0 The file's owner can also
\pard\tx960\tx1920\tx2880\tx3840\tx4800\tx5760\tx6720\tx7680\tx8640\tx9600\fc0 set the delegate of an object it owns to be some
It's conceptually impossible to make the connections in Interface Builder, because there's no way to know which
\i instance
\i0 of an object from one nib file will be connected to an instance of some object from another nib file. Each nib file will be loaded at a different time during the program execution, and any nib file can get loaded multiple times. Only your code "knows" when the various objects will get created—namely, when you call
\b loadNibSection:owner:
\b0 . Remember that nib files are just templates; the objects are unarchived when you load the nib file. When you make connections in Interface Builder, you're really just making the template of these connections. Only when the nib file is loaded do the objects and their interconnections get instantiated, so to speak. If the other nib file hasn't been loaded yet, you can't connect to its objects, since they don't exist in your program yet. That's why connections are limited to nib files. It's also one reason every nib file must have an owner: so that objects from that nib file can communicate with other objects in your program.\
\
The same logic applies to loading the same nib file multiple times. A typical use of loading the same nib file multiple times is in applications that have the notion of a document. The document is described by a nib file that gets loaded each time you want a new document (usually when the user clicks on the "New" menu). There should generally be a new instance of the owner of the nib file for each time you want to load the same nib file. The only way to communicate between the objects in different documents is through their owners.\
\
One example of multiply loaded nib files is /NextDeveloper/Examples/SoundEditor. In this app, SoundController is the main object that loads in the application's main nib file. It also is responsible for creating SoundDocuments, each of which loads in its own nib data. In other words, a new instance of the SoundDocument class is the file's owner for each "instance" of SoundDocument.nib—or more precisely, for the objects collectively unarchived each time \
\b0 method. Although it wasn't necessary, there could have been methods in SoundDocument to return the objects "inside" each SoundDocument's nib file. For example, SoundDocument could have implemented a method called
\b -soundView
\b0 that returned the variable
\b mySoundView
\b0 , which is an IB outlet. This way any other objects could have talked to the SoundView, by messaging SoundController to get the current document (with the
\b document
\b0 method), and then messaging the current document to get its SoundView (with the
